ソフトウェアアーキテクチャの基礎輪読会 5章
日付：11/8
調査者：iNoma.icon
章のまとめ
どんな内容が書かれているか？
要約
アーキテクチャ特性を導くスキルの訓練として「カタ」が有効 5.1章
ドメインのステークホルダーの関心をアーキテクチャ特性に翻訳する、というアプローチ
ドメインのステークホルダーとアーキテクトは、異なる言語を話す
ステークホルダー側で用いられる言葉の例
合併、買収
ユーザー満足度
市場投入までの時間
競争上の優位性 ... etc.
アーキテクトが用いる言葉(-ility)の例
スケーラビリティ
学習容易性
耐障害性 ... etc.
table:ドメインの関心事からアーキテクチャ特性への翻訳例(一部)
ドメインの関心事 アーキテクチャ特性
合併・買収 相互運用性、スケーラビリティ、適応性、拡張性
市場投入までの時間 アジリティ、テスト用意性、デプロイ容易性
ユーザー満足度 アジリティ、テスト容易性、デプロイ容易性、スケーラビリティ、可用性、耐障害性
競争優位性 シンプルさ、フィジビリティ
takasshii.iconアジリティってなんだっけ iNoma.icon敏捷性と訳される事が多い？
「アジャイル開発」のAgileの派生語です
takasshii.iconなるほど
翻訳における注意点
ドメインの関心事とアーキテクチャ特性は1:1対応しない
複数のアーキテクチャ特性によってドメインの目的が達成される
一つのアーキテクチャ特性のみに執心するのは失敗を産む
アンチパターン
takasshii.iconやりがち（反省）
アーキテクチャ特性を増やすと、システムが複雑になっていく
重視するアーキテクチャ特性を決定するのに有効な手法
「アーキテクチャ特性のリストのうち最も重要な3つをステークホルダーに選ばせる」
優先順位を決める手法は一見有効そうだが、ステークホルダー全員が優先順位に同意することは稀
何が最も重要であるかの議論を促し、トレードオフの分析にも繋がる
takasshii.iconアーキテクチャ特性はトレードオフ(よく出てきた） 要件からアーキテクチャ特性を抽出する
5.2章
要件文書に明示されているものからアーキテクチャ特性を抽出するアプローチ その際、アーキテクトの持つドメイン知識が判断の材料となることもある
アーキテクトはドメイン知識が重要である
例
大学生の履修登録アプリケーションでは、締め切り直前にアクセス集中と予想できる
カタを用いた訓練
限られたキャリアの中でアーキテクトとしてスキルの訓練を行うために、「Architectural Katas」というカリキュラムがある
takasshii.iconKatasって型ってことなのかw
武術に由来
Typeの型ではない
takasshii.icon:naruhodo
ドメインの言葉で書かれた問題から、アーキテクチャを考える課題
正しいフォームやテクニックを重視
カタ(問題)
記述
全国展開しているサンドイッチ店が、電話注文に加えてオンライン注文を可能にしたいと考えている
ユーザー数
数千。いずれは数百万
要件
1.ユーザーが注文をすると、サンドイッチを受け取れる時間と店舗までの道順を提示する
2. 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを宅配する
3. モバイル端末でのアクセシビリティ
4. 全国向けにデイリープロモーション用メニューやスペシャルメニューを提供する
5. エリア限定でデイリープロモーション用メニューやスペシャルメニューを提供する
6. オンラインか直接、または配達時の支払いが可能
追加コンテキスト
7. サンドイッチ店はフランチャイズで、オーナーはそれぞれ異なる
8. 親会社は近日中に海外展開を予定している
9. 安い労働力を雇って利益を最大化するのが企業のゴール
本書でのアプローチ
まず、要件文書を読み、アーキテクチャ特性を抽出
明示的な特性
例
ユーザー数：数千。いずれは数百万
ユーザー数の増加が読み取れるため
リクエストのバースト（局所的な増加）に対応できる能力
takasshii.iconこれ思いつかんかった。:tasikani
サンドウィッチ店のトラフィックは食事の時間帯にバーストすると予想されるため
(暗黙的な特性が「5.3.1 明示的なアプローチ」内で触れられているが、「要件から読み取れる範囲の暗黙的な特性」程度の意味だと考えるiNoma.icon)
↑の例のように、要件文書からアーキテクチャ特性への変換を行っていく。以下同様に、
1.ユーザーが注文をすると、サンドイッチを受け取れる時間と店舗までの道順を提示する
外部地図サービスの利用が信頼性に影響を与えるかもしれない 2. 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを宅配する
アーキテクチャへの影響なし
3. モバイル端末でのアクセシビリティ
モバイル特有の性質から、アーキテクチャ特性が定義されうる
不安定なネットワーク環境でのパフォーマンスなど？iNoma.icon
takasshii.iconアクセシビリティって社会的弱者への対応かと思った
4. 全国向けにデイリープロモーション用メニューやスペシャルメニューを提供する
5. エリア限定でデイリープロモーション用メニューやスペシャルメニューを提供する
対応方法1
以下のトレードオフを抱えそうiNoma.icon
対応方法2
以下のトレードオフを抱えそうiNoma.icon
takasshii.icon:wakaru
それぞれのトレードオフを考える必要がある
開発者やPM、運用チームとの協力が必要不可欠
実装チームと切り離してアーキテクチャを決定してはいけない
6. オンラインか直接、または配達時の支払いが可能
暗黙的に、明示するほどではない程度のセキュリティが期待されている 7. サンドイッチ店はフランチャイズで、オーナーはそれぞれ異なる
店舗毎に財務状況やスタッフのスキルセットや、時間的余裕などが異なると予想される
アーキテクチャにコスト制限がかかる可能性があり、調査が必要
takasshii.icon確かに
8. 親会社は近日中に海外展開を予定している
国際化対応が必要である
アーキテクチャレベルではなく、設計レベルの問題
9. 安い労働力を雇って利益を最大化するのが企業のゴール
安価で雇える人材でもシステムを扱えるように、ということだと思うiNoma.icon
これもアーキテクチャレベルではなく、設計レベルの問題とされている
暗黙的な特性
信頼性
システムが稼働し続ける必要があるが、明記はされていない
セキュリティ
決済をサードパーティに任せる場合は、最低限で良い
カスタマイズ性
要件からの抽出でも
takasshii.iconこっから何が大事か取り出すのむずそ〜（ ; ; ）
応用
記述
DroidKaigiでは、当日のセッションを確認できるモバイルアプリを開発したいと考えている
ユーザー数
1000人程度
要件
1. ユーザーは、各セッションについて、会場や開始時間、詳細を含む情報を確認できる
2. ユーザーは、セッションに対してタグやワードで検索を行える
3. 誰でもこのアプリ開発にContributeできる
takasshii.iconこれむずいな
追加コンテクスト
このアプリは、今年のイベントのためだけに使われる
Contributionを通してAndroid開発コミュニティを活性化させることが一番の目的
質疑応答